Een vlotte overgang van build naar run
Tijdens vorige blogs hebben we gesproken over de continuous delivery flow. Dit bevat alles wat nodig is om met een korte doorlooptijd en op een iteratieve en veilige manier software naar productie te brengen. De verantwoordelijkheid blijft bij die overgang bij hetzelfde team. Dit is een gevolg van de DevOps-attitude: you build it, you run it. Het bouwen en in de lucht houden van een stuk software wordt dus niet losgekoppeld van elkaar, enkel de spelregels veranderen.
Om dit te duiden, duiken we even in de manier van werken van NASA. Zij maken een duidelijk verschil tussen launch control en mission control. Launch control is verantwoordelijk tot de teller op 0 staat en de raket ontsteekt. Totdat punt kunnen ze op elk moment afbreken. Dit is te vergelijken met een continuous delivery pipeline die ingebouwde checks bevat en het proces kan onderbreken als er niet aan de minimale eisen wordt voldaan. Echter, eens de raket vertrokken is, neemt mission control het over omdat het vanaf dan onmogelijk is om de vliegende raket zomaar te stoppen. Alles wordt gemonitord, als er iets voorvalt kunnen ze nog proberen om de schade te beperken. Dit kan je deels vergelijken met het in productie brengen van software. Als het live staat en de gebruikers gaan ermee aan de slag, is het niet zo eenvoudig om dit terug om te keren. Gelukkig bestaan er wel enkele releasestrategieën waarbij we meer controle houden dan in de ruimtevaart.
-01.png)
Releasestrategieën om de controle zoveel mogelijk in de hand te houden
Door een opsplitsing te maken tussen deployment van een nieuwe versie van bepaalde artifacts en de release van bepaalde features, gaat er een hele wereld aan mogelijkheden open. Deploy gaat over de binaries (een reeks uitvoerbare bestanden die een bepaalde functie zullen uitvoeren) terwijl release over de functionaliteit gaat. In te veel gevallen gaan deze twee zaken samen. Met volgende strategieën hou je veel meer de controle:
- Blue-geen deploy: er wordt een nieuwe versie naast de oude gezet. Een zelfgekozen pilootgroep van gebruikers krijgt toegang tot de nieuwe versie zodat ze deze in productie kunnen testen. Als alles goed verloopt kan de switch worden gemaakt zodat iedereen de nieuwe versie gebruikt.
- Canary release: deze strategie heeft z’n naam te danken aan de kleine gele vogeltjes die vroeger gaslekken in mijnen vroegtijdig opspoorden. Ook hier staan er weer twee versies naast elkaar. Een willekeurige 10% van de gebruikers krijgt via load balancing de nieuwe versie te zien. Dat percentage wordt stillaan omhoog getrokken. Als er iets verkeerd gaat, daalt het percentage weer.
- Feature flags: bepaalde nieuwe features zijn al wel beschikbaar in de code, maar nog niet zichtbaar voor gebruikers. Dit maakt testen in productie mogelijk. Het is zelfs niet ondenkbaar dat een gebruiker de keuze krijgt of hij het oude scherm van een bepaalde feature gebruikt of al het nieuwe. Zij krijgen dan ‘wil je de bèta versie al testen’-vraag voorgeschoteld. Tevens is het op basis hiervan ook eenvoudiger om auto-healing concepten in te bouwen. Als het monitoringsysteem detecteert dat er een probleem is met de nieuwe feature sinds de activatie van een bepaalde feature flag, kan die bijvoorbeeld automatisch terug afgezet worden.
